This replaces both with a new Tag system, which exposes both
argumentless insertions and argument-handling transformations in one
registry, with one type hierarchy.

I hope to open the door to piggybacking on these tag resolvers to handle serialization as well at some future point.

Still to do:

• examinability of built-in Tag implementations, to ease debugging
• correct the message passed to exceptions created in Context
• names?
• API-ification of ElementNode (related to text-minimessage: add deserialization method returning parsed tree #658)
• [ ] common impl for rainbow and gradient tags happening later, not an API-visible change
• [ ] for rainbow and gradient length calculations, a way to distinguish between pre-calculated and lazily computed Inserting types (does this make sense to be restricted to just placeholders even?) delayed
• ArgumentQueue/other helpers for parsing tag arguments (something providing API along the lines args.pop() that auto-throws an exception if the required argument isn't present, other helpers like Tag.Argument#asDouble(): OptionalDouble)

Overview

The changes in this PR aim to unify two very similar APIs to reduce the number of concepts developers have to deal with. In doing so, I've managed to reduce some layers of abstraction, and provide the full capabilities of each system for every use case. This has resulted in some shuffling around:

As you can see, the concepts of a factory/placeholder and resolver/registry have been merged -- it is possible to consider a Placeholder or Factory as a simple case of a resolver, which only contains one element.

Types of Tags

Inserting

These tags are fairly straightforward: they represent a literal Component. The vast majority of Tag implementations will want to be Inserting tags. Inserting tags may also optionally be self-closing -- by default, this is only true for tags created by resolvers from the Placeholder class, so that placeholders are self-contained.

Modifying

Modiying tags have the ability to perform transformations on the entire component tree of their children after it has been created. This is used for the <rainbow> and <gradient> tags, but can be applied to any other more complex transformations.

PreProcess (or minimessage)

These tags have a value of a MiniMessage string. They are unique in that they're applied before any sort of parsing begins, so can be fragments rather than entire strings.

Examples

The implementations of the built-in tags for representing components provide a starting point for examples of how this system works. However, to address some more simple cases, and provide examples of a custom tag with richer functionality:

A simple case with placeholder-equivalent tags:

    final String input = "[<prefix><player><suffix>] >> <message>";
    final TagResolver placeholders = TagResolver.combining(
      Placeholder.parsed("prefix", "<red>Admin </red><blue>"),
      Placeholder.component("player", text("kashike")),
      Placeholder.parsed("suffix", "</blue>"),
      Placeholder.component("message", text("Hello!"))
    );
    
    final Component parsed = MiniMessage.miniMessage().deserialize(input, placeholders);

A fancier case, with custom logic

This creates a custom tag that performs all the styling needed to create a standard hyperlink using an HTML-like a tag:

  Component aTagExample() {
    final String input = "Hello, <a:https://kyori.net>click me!</a> but not me!";
    final MiniMessage extendedInstance = MiniMessage.builder()
      .tags(b -> b.resolver(TagResolver.resolver("a", MiniMessageTest::createA)))
      .build();

    return extendedInstance.deserialize(input);
  }

  static Tag createA(final ArgumentQueue args, final Context ctx) {
    final String link = args.popOr("The <a> tag requires exactly one argument, the link to open").value();

    return Tag.styling(
      NamedTextColor.BLUE,
      TextDecoration.UNDERLINED,
      ClickEvent.openUrl(link),
      HoverEvent.showText(Component.text("Open " + link))
    );
  }